Recently, as a result of the progress of semiconductor processing technologies, integration of a large number of transistors on a semiconductor chip has been possible, so that LSI devices called SoC devices can be realized, in which an entire system is packaged within a single chip.
The requirement is not only that SoC devices be capable of high performance but also that these devices be flexible enough to accommodate new specifications and demands. To deal with this, a SoC device usually employs an architecture in which a general-purpose microprocessor core (which will be simply referred to hereinbelow as a processor core) is provided as a base and improved performance is achieved by the addition of a co-processor and a hardware-accelerator (which will be simply referred to hereinbelow as an accelerator) and by the use of a multi-core configuration while flexibility is realized by controlling the co-processor and accelerator based on the software (user programs) stored in the processor core.
For example, in non-patent document 1 (Ricardo E. Gonzalez, “Xtensa: A Configurable and Extensible Processor”, IEEE MICRO Magazine, Volume 20, Issue 2, March-April 2000, pp. 60˜70.), non-patent document 2 (Steve Leibson/James Kim, “Configurable Processors: A New Era in Chip Design,” IEEE Computer Magazine, Volume 38, Issue 7, July 2005, pp. 51-59) and patent document 1 (Japanese Patent Application Laid-open No. 2004-288203), processor cores as SoC devices that permit functional extension by adding co-processors and accelerators are exemplified.
When such a SoC device is debugged, it is necessary to simultaneously debug both the software (user programs) for operating the processor core and the additional hardware such as co-processors, accelerators and the like for realizing additional functions. ICEs (In-Circuit Emulators) are well known as tools that are used to debug software (user programs). Logic analyzers are well known as tolls that are used to debug hardware.
An ICE provides a debug environment in which the processor core provided on a SoC device is abstracted in the programming model level. More specifically, this provides functions such as reading/writing of the internal register provided for the processor core, reading/writing of the system memory, execution control (start of execution from a designated address and stop at one of break points) and the like, as described in non-patent document 3 (Shigetoshi Yamamoto/Kazutoshi Arimatsu, “An installed device and debug environment”, CQ Publishing Co., Ltd., Interface, March 2002, pp. 49-53). It should be noted that in the ICE, hardware-level information is hidden from the user.
A typical ICE configuration will be described using FIG. 1.
FIG. 1 is a block diagram showing a configuration of a conventional ICE used as a debugger of user programs.
As shown in FIG. 1, ICE unit 6 includes break detecting circuit 7 to realize execution control of processor core 2. Break detecting circuit 7 monitors the state of processor core 2 (which will be simply referred to hereinbelow as the processor state), such as the value on the program counter of processor core 2, instruction words being executed, and the like. When the processor state coincides with the previously designated break condition, specifically, when the value on the program counter reaches the previously set value or when a well-known trap instruction is executed, the circuit outputs a break signal (hereinafter, occurrence of a break signal will be called “a software mode event”) so as to cause processor core 2 to transition from the execution state of a user program to the debuggable state (debug state) of the user program. Here, the trap instruction may also be called, software interrupts, debug instruction, break instruction or the like.
ICE UI (User Interface) 8 sets up the break condition on which break detecting circuit 7 is caused to output a break signal, in accordance with operations from the user. ICE UI 8 also implements reading and writing of the internal register of processor core 2 being debugged, in accordance with operations from the user. At this time, ICE unit 6 executes the process, based on the software for reading from, and writing to, the internal register of processor core 2 being transitioned to the debug state, or the system memory, to thereby assist the user to debug the user program.
For example, on pp. 13-40 in non-patent document 4 (“ARM1156T2F-S Technical Reference Manual, Revision: r0p0”, ARM Limited, 2005, internet <URL: http:/www.arm.com/pdfs/DD10290C_arm1156t2fs_r0p9_trm.pdf>), there is disclosed a processor of ARM Limited, Britain, known as an embedded processor core, which realizes the function of an ICE unit by making a transition to software controller, called “Monitor target”, when an interrupt signal called “Debug exception” occurs.
A logic analyzer, as described in, for example, non-patent document 5 (Nobutaka Arai “the operational principle of a logic analyzer”, CQ Publishing Co., Ltd., Transistor Technology, July 2003, pp. 128-134), is a device for monitoring and recording the temporal change (waveform) of a predetermined signal (observed signal) designated by the user. A typical logic analyzer configuration will be described using FIG. 2.
FIG. 2 is a block diagram showing a configuration of a logic analyzer used as a conventional hardware debugger.
As shown in FIG. 2, logic analyzer unit 20 includes trigger detecting circuit 12, trace memory 13 and logic analyzer UI 14.
Trigger detecting circuit 12 compares the user-designated trigger condition with a predetermined input signal, and generates a trigger signal when these coincide with each other (hereinafter, occurrence of this trigger signal will be called “a hardware mode event”).
Trace memory 13 stores the observation signals before and after the occurrence of a trigger signal as it is, out of the observation signals output from additional hardware 3. However, the observation signals to be stored into trace memory 13 may be optionally subjected to the least necessary processes such as being shaped in waveform, being synchronized with a predetermined sampling clock and the like.
Logic analyzer UI (User Interface) 14 sets up the trigger condition on which trigger detecting circuit 12 is caused to generate a trigger signal, in accordance with operations from the user. Logic analyzer UI 14 also displays signals that are stored in trace memory 13.
FIG. 3 shows how the software (user programs) operating on processor core 2 integrated in SoC device 1 and additional hardware 3 are debugged using an existing ICE and logic analyzer. FIG. 3 shows the manner in which the processor state is read out from processor core 2 integrated in SoC device 1 by ICE unit 6 and shows the situation in which the signals to be observed (observed signals) are monitored from additional hardware 3 such as co-processor 4, accelerator 5, etc., by logic analyzer unit 20.
Since in this simultaneous debugging using ICE unit 6 and logic analyzer unit 20, ICE unit 6 and logic analyzer unit 20 are independent devices, the lack of sufficient cooperation between these devices leads to a problem in which it is difficult to achieve efficient debugging based on the cooperation of ICE unit 6 and logic analyzer unit 20.
As an example using cooperation of ICE unit 6 and logic analyzer unit 20, technology described in non-patent document 6 (“Debug by cooperation of a logic analyzer and an ICE)”, CQ Publishing Co., Ltd., Interface, October, 2000, p. 108) is well known. Non-patent document 6 describes an example in which a break signal for the co-processor, which is output from the ICE, is used as a trigger signal for the logic analyzer, and in which the times corresponding to the execution history (“History window of WATCHPOINT” in non-patent document 6) stored in the ICE are displayed with the signal waveform of the observation signals, on the logic analyzer.
As stated above, since, in the conventional debugger, the ICE used for debugging user programs and the logic analyzer used for debugging hardware are independent devices, the lack of sufficient cooperation between these devices leads to a problem in which it is difficult to achieve efficient debugging based on the cooperation of these devices.
Although the above cited non-patent document 6 describes an example in which a software mode event is used as a trigger signal for the logic analyzer, no method is shown for using a hardware mode event as a break signal for the ICE unit. Therefore, a problem occurs in which, even if it is desirable to stop operation of the entire system by causing the processor core to transition to the debug state when an internal signal from the additional hardware or when an external signal has reached a particular state, it is impossible to execute this activity.
In this way, since the existing ICE and logic analyzer are not sufficient enough to cooperate with each other, a problem occurs in which it is difficult to debug a SoC device that operates based on the cooperation of hardware and software (user programs).